Declare the desktop app as the preferred bridge channel - #271
philipp-winterle wants to merge 1 commit into
Conversation
The server's UI operation bridge picks whichever UI connected first as the channel that answers every MCP and CTL operation. With the desktop app and a browser tab both open, which one that is comes down to startup order, and the user has no way to steer it. The bridge now accepts an optional priority in the operations message. Sending 1 from the desktop shell and 0 from a browser tab makes the app the user is actually driving win, whatever the connection order was. isDesktopShell() reads the injected desktop API directly, because it has to answer synchronously here - desktopVersion never resolves in a browser, so it can't tell the two apart.
|
|
|
@philipp-winterle, I'm going to close this and httptoolkit/httptoolkit-server#246 I'm afraid. It's an interesting idea, but I think it adds complexity for a pretty niche scenario (running both the desktop app and the UI independently on the same machine) and I'm not sure the result is correct anyway - if you're using the UI, it's totally possible that you want the MCP to control it instead of the desktop app. If anything the UI is the case that's more convenient for automation scenarios. The "first session wins" model is simpler and clearer imo. |
|
Got it. Iam using the app without the ui and the mcp to be controlled and read by an python app. The UI was the human interface I was going to read. But they had some issues being connected to the same websocket. Iam fine if do not want to add this. I have a patch file for this use case. |
3 participants
The problem
The server's UI operation bridge picks whichever UI connected first as the
channel that answers every MCP and CTL operation, and whose account decides
isPaidUser(). With the desktop app and a browser tab both pointed at the sameserver, which one wins comes down to startup order, and the user has no way to
steer it.
The change
The bridge accepts an optional
priorityin the operations message(httptoolkit/httptoolkit-server#246). The desktop shell sends 1, a browser tab
sends 0, so the app the user is actually driving takes the role whatever the
connection order was.
isDesktopShell()reads the injected desktop API directly because it has toanswer synchronously here.
desktopVersioncan't be used for this - by its owncomment it never resolves in a browser, so it cannot tell the two apart.
Test plan
tsc --noEmitreports nothing in either changed file. (The repo haspre-existing type errors elsewhere under a bare
tsc, so this is scoped tothe diff.)
server-operation-bridge.tshas no test file today andno seam to reach the socket through, and the behaviour this field drives is
covered by the server-side PR's tests. Glad to add one if you can point me
at the shape you'd want.
shell set up, only the local web UI, where
isDesktopShell()correctlyreports false.